The rule filter did not changed, so it makes no sense to trigger "afterUpdateRuleFilter".

If you have special logic to apply to the DOM, then listen to "afterSetFilters" too.

Hey, when I opened the PR yesterday it was at the end of a very tiring workday. I probably wasn't as descriptive as I could've been, so let me elaborate.

We need to trigger afterUpdateRuleFilter there because https://github.com/VanTanev/jQuery-QueryBuilder/blob/96f2d228eb3a6b6b8e23eaa0179edcd5f4d96b5a/src/plugins/change-filters/plugin.js#L53 creates a <select> and triggers afterCreateRuleFilters but does not set its value.

In my use case, I listen to ``afterCreateRuleFiltersand attachChosen` on the select. The chosen will not have any value set.

Afterwards, you manually call val() on the original select, but I have no way to know that the value has been updated, and my Chosen is left without selection.

That's why we need to trigger the afterUpdateRuleFilter event - because line 55 does exactly that, it updates the value of the <select>.

Then, in my plugin I can do:

    this.on('afterUpdateRuleFilter', function(e, rule) {
        rule.$el.find(QueryBuilder.selectors.rule_filter).trigger('chosen:updated');
    });

An alternative approach could be to change the template for filterSelect from:

<option value="{{= filter.id }}">{{= it.translate(filter.label) }}</option>

to:

<option value="{{= filter.id }}"
  {{? it.rule.filter && it.rule.filter.id && filter.id === it.rule.filter.id }}
    selected="selected"
  {{?}}
>{{= it.translate(filter.label) }}</option>

I should note that this problem arises both when manually using setFilters() and when you pass a rules object to the constructor of the plugin.

Yeah I understood the first time, but my point is that events triggered by the plugin represent changes in the data model, and in this case the data model did not changed, only the DOM.

What you want is exactly what the plugin his doing itself for 'bt-selectpicker' plugin

Hence my suggestion to also listen to 'afterSetFilters' and refresh all Chosen at once.

I do believe that either of my proposed changes are a cleaner path to achieve this behavior.

If the data did not change, then we probably want to render the DOM in the right state immediately by updating the template to set the selected property.

Right. Actually my assertion is false because events like "afterCreateRuleFilters" do not reflect a change in the model.

I'll see tomorrow.

Thank you.

About rules constructor : #342